© 2025 Kênh Chuỗi Khối Việt . All Rights Reserved.
Biên tập theo: Với sự mở rộng không ngừng của hệ sinh thái Ethereum, việc làm thế nào để mở rộng mạng mà vẫn giữ an toàn và tính phân quyền trở thành chủ đề chính. Trong bài viết này, Vitalik Buterin đã trình bày rõ hơn con đường mở rộng của Ethereum: trong ngắn hạn, thông qua việc tối ưu hóa cơ chế Gas, cải tiến công nghệ như đa nhiệm vụ xác minh khối để tăng cường hiệu suất thực thi; trong dài hạn, dựa vào ZK-EVM và cấu trúc dữ liệu blobs để thúc đẩy mở rộng mạng.
Nhìn chung, con đường này cung cấp một loạt các giải pháp mở rộng theo từng giai đoạn, nhằm mục tiêu cung cấp nền tảng cho việc tăng cường khả năng mạng của Ethereum trong những năm tới.
Dưới đây là bản gốc:
Bây giờ chúng ta sẽ nói về việc mở rộng. Đây chủ yếu chia thành hai phần: mở rộng ngắn hạn và mở rộng dài hạn.
Về mở rộng ngắn hạn, tôi đã viết về vấn đề này ở một số nơi khác. Ý tưởng cơ bản như sau:
· Danh sách truy cập cấp khối (block-level access lists) (sẽ được triển khai trong bản nâng cấp Glamsterdam) cho phép xác minh khối được thực hiện đồng thời.
Trong một lần điều chỉnh gas ở Glamsterdam, chi phí bổ sung này sẽ được tăng đáng kể (ví dụ, tăng lên 60000). Mục tiêu của việc làm này là trong việc tăng giới hạn gas, đồng thời làm cho tốc độ mở rộng của khả năng thực thi cao hơn nhiều so với tốc độ mở rộng của quy mô trạng thái.
Về lý do, tôi đã viết trước đó rồi: https://ethresear.ch/t/hyper-scaling-state-by-creating-new-forms-of-state/24052
Do đó, ở Glamsterdam: Thao tác SSTORE này sẽ tiêu tốn 5000 "gas thông thường", ví dụ 55000 "gas tạo trạng thái"
Cần lưu ý rằng: Gas tạo trạng thái sẽ không tính vào giới hạn gas giao dịch khoảng 16 triệu.
Điều này có nghĩa là: Việc tạo hợp đồng lớn hơn hiện tại sẽ trở nên khả thi.
Ở đây sẽ xuất hiện một vấn đề: Thiết kế mặc định của gas trong EVM chỉ có một chiều, ví dụ: các opcode GAS, CALL đều dựa trên giả định này.
Phương pháp giải quyết của chúng tôi là duy trì hai hằng số không đổi:
Nếu bạn sử dụng X gas để thực hiện một cuộc gọi, thì cuộc gọi đó sẽ sở hữu X gas, có thể sử dụng cho "hoạt động thông thường", hoặc "tạo trạng thái", hoặc các chiều khác có thể được thêm vào trong tương lai.
Nếu opcode GAS nói cho bạn hiện đang có Y gas, sau đó bạn thực hiện một cuộc gọi tiêu tốn X gas, thì sau khi cuộc gọi trả về, bạn vẫn có ít nhất Y − X gas, có thể sử dụng cho các hoạt động tiếp theo.
Cách triển khai cụ thể là: chúng tôi giới thiệu N+1 chiều gas. Mặc định, N = 1 (tạo trạng thái), một chiều bổ sung được gọi là reservoir (hồ chứa).
Logic thực thi của EVM là:
Nếu có thể, ưu tiên tiêu tốn gas của chiều đặc biệt
Nếu không đủ, thì sẽ tiêu thụ từ reservoir.
Ví dụ, nếu bạn có: (100000 gas khởi tạo trạng thái, 100000 reservoir)
Nếu bạn sử dụng SSTORE để tạo ba trạng thái mới, quá trình thay đổi gas sẽ như sau: (100000, 100000)→ (45000, 95000)→ (0, 80000)→ (0, 20000)
Trong thiết kế này:
Opcode GAS trả về reservoir
CALL sẽ truyền một lượng gas cụ thể từ reservoir và đồng thời truyền tất cả gas không phải từ reservoir
Sau này chúng ta sẽ giới thiệu thêm định giá đa chiều (multi-dimensional pricing), cho phép các chiều tài nguyên khác nhau có giá gas dao động khác nhau.
Điều này sẽ mang lại:
Khả năng bền vững kinh tế dài hạn tốt hơn
Hiệu quả phân bổ tài nguyên tốt hơn
Xem chi tiết tại: https://vitalik.eth.limo/general/2024/05/09/multidim.html
Và cơ chế reservoir chính là cách giải quyết vấn đề cuối cùng được đề cập trong bài viết đó về các cuộc gọi con (sub-call).
Mở rộng dài hạn chủ yếu bao gồm hai hướng: ZK-EVM và Blobs.
Đối với blobs, chúng tôi dự định liên tục cải tiến PeerDAS, hy vọng cuối cùng đạt được khả năng xử lý dữ liệu khoảng 8 MB/giây.
Quy mô này:
Đủ để đáp ứng nhu cầu của Ethereum bản thân
Và không định trở thành một "tầng dữ liệu toàn cầu".
Hiện tại, blobs chủ yếu được sử dụng cho L2. Kế hoạch trong tương lai là cho dữ liệu khối Ethereum chính thức được viết trực tiếp vào các blobs.
Mục tiêu của việc này là để mọi người có thể xác minh một mạng lưới Ethereum được mở rộng mạnh mà không cần tải xuống và thực thi lại toàn bộ chuỗi:
ZK-SNARKs loại bỏ nhu cầu thực thi lại
PeerDAS + blobs cho phép xác minh tính khả dụng dữ liệu mà không cần tải xuống toàn bộ dữ liệu
Đối với ZK-EVM, mục tiêu của chúng tôi là tăng dần sự phụ thuộc của mạng lưới vào nó.
Năm 2026: Các khách hàng hỗ trợ ZK-EVM sẽ xuất hiện, cho phép nút tham gia chứng nhận bằng ZK-EVM. Tuy nhiên, chúng vẫn chưa đủ an toàn để mạng lưới dựa vào chúng để chạy. Tuy nhiên, việc khoảng 5% mạng sử dụng chúng là chấp nhận được. (Nếu ZK-EVM gặp vấn đề, bạn sẽ không bị phạt mất tiền góp vốn, nhưng có thể xây dựng trên các khối không hợp lệ và mất lợi nhuận.)
Năm 2027: Chúng tôi sẽ bắt đầu đề xuất cho một tỷ lệ lớn hơn của các nút chạy ZK-EVM, đồng thời tập trung vào việc xác thực hình thức và nâng cao tính bảo mật. Ngay cả khi chỉ có khoảng 20% mạng sử dụng ZK-EVM, chúng ta cũng có thể tăng đáng kể gas limit vì điều này cung cấp một con đường xác minh chi phí thấp cho solo staker, trong khi tỷ lệ solo staker chính thống không vượt quá 20%.
Khi công nghệ trở nên chín muồi: Chúng ta sẽ giới thiệu cơ chế chứng minh bắt buộc 3 trên 5. Nghĩa là, một khối phải chứa ít nhất 3 trong số 5 hệ thống chứng minh khác nhau để được coi là hợp lệ. Đến lúc đó, chúng ta dự kiến rằng hầu hết các nút sẽ phụ thuộc vào chứng minh ZK-EVM ngoại trừ những nút cần làm chỉ mục.
Dài hạn: Tiếp tục cải thiện ZK-EVM để nó mạnh mẽ hơn, và tiến hành xác thực hình thức nghiêm ngặt hơn. Giai đoạn này cũng có thể liên quan đến thay đổi ở cấp độ máy ảo, như RISC-V và các hướng khác.
Chi tiết xem tại: https://ethresear.ch/t/hyper-scaling-state-by-creating-new-forms-of-state/24052
[Liên kết gốc]